Cloud-based security services (and on premise middle boxes acting as Transport Layer Security (TLS) proxies) are largely based on being able to intercept or proxy flows so as to subject flows to security inspection. These services range from web security services, firewalls, malware detection to services such as data loss prevention (DLP), distributed denial of service (DDoS) mitigation, etc. This is also relevant in situations in which cloud services rely on service function chaining i.e. a service function classifier channels flows across proxy services, especially for service functions that span across service function chain domains (different administrative domains).
In case of a DDoS attack, traffic is temporarily steered to a DDoS mitigation provider during a DDoS attack until the attack is mitigated. Content providers manually upload public certificates and private keys to the DDoS mitigation provider to block attacks at Layer 7 or the TLS layer for secure servers. The is especially complicated with DDoS Open Threat Signaling (DOTS), where DDoS mitigation is dynamically delegated to an alternate DDoS mitigation provider and the private keys are conveyed to the alternate DDoS mitigation provider. In all of these cases, the solutions are dependent on the fact that payload needs to be inspected either for security, monitoring or classification.
A concern with such solutions is that these services, acting as man-in-the-middle (MITM) entities, may modify or compromise payload, especially when traffic flows through multiple proxies. This concern is across clients (end-users), proxies and servers (content providers).